A variety of programs on the market allow a developer (e.g., a web developer) to create web pages, websites, interactive applications, and the like for use by end users (e.g., visitors to websites). Examples of such programs include DREAMWEAVER™ and FLEX BUILDER™, each available from MACROMEDIA INC. of San Francisco, Calif. DREAMWEAVER™ is an Integrated Development Environment (IDE) for creating Hypertext Markup Language (HTML) websites. FLEX BUILDER™ is an IDE for creating Rich Internet Applications (RIAs), and it uses MXML™ as its native development code for RIAs. RIAs are interactive, multimedia, applications, that may run on client-side players, for example, MACROMEDIA INC.'s FLASH™ player. MXML™ is an Extensible Markup Language (XML)-based language commonly used to create RIAs and it looks similar in some ways to HTML. A developer may write code in a text editor or FLEX BUILDER™ and save the MXML™ file to a FLEX™ server. The FLEX™ server compiles the code, including MXML™ and ACTIONSCRIPT™ code, into a file, such as a ShockWave Flash (SWF or “Small Web Format”) file, that can be downloaded and executed on a user's machine. ACTIONSCRIPT™ code, available from MACROMEDIA INC, is a scripting language that is similar to JAVASCRIPT™ in that both ACTIONSCRIPT™ and JAVASCRIPT™ are based on the ECMA-262 standard.
FIG. 1 is an illustration of example system 100, adapted to provide a RIA to an Internet user. System 100 includes server 101 with compiler functionality, network 102, downloaded file 103, and user computer 104 with client application 105. Client application 105 in this example, is a FLASH™ player or FLASH™ player plug-in for a web browser. A developer builds a RIA that includes a UI and saves it in an MXML™ file on server 101. When a user at computer 104 requests the RIA, server 101 accesses the MXML™ file and compiles it into SWF (commonly pronounced “swiff”) file 103. SWF file 103 contains, among other things, compiled ACTIONSCRIPT™ in the form of bytecodes. SWF file 103 is downloaded by client application 105 over network 102 for display to the user.
FLEX™ provides a way to generate SWF file 103. As explained above, a developer may open FLEX BUILDER™ or a text editor, create a document with MXML™ tags, and save the file to server 101, which is running the FLEX™ server. The FLEX™ server includes a compiler that compiles the saved MXML™ code into SWF file 103. SWF file 103 is then run, for example, on client application 105 that is enabled with a FLASH™ player plug-in. FLASH™-based applications are known for graphics and animation, and the appearance of the graphics is due, in large part, to styles applied to the UI objects.
Cascading Style Sheets (CSS) is a language that is often used in HTML web pages to apply styles to visual objects. CSS was developed in an attempt to separate style formatting from structure formatting and content. In a general sense, styles usually affect the visual appearance of an object, and include, for example, color and font size, whereas structure formatting usually specifies the objects and arrangement thereof on a user's screen. Just as HTML web pages utilize CSS, applications created with MXML™ also make use of CSS to apply style formatting. For any given object in an HTML or MXML™ document, several styles may apply. Accordingly, CSS provides a hierarchy of rule sets to determine which styles actually control how the object is rendered, as explained more fully below.
CSS code to implement a rule set that all buttons have a font size of twenty is illustrated in the following example:
Button {font-size:20}
The code in the example above automatically applies the rule set to all button objects in a particular application. It is referred to as a type rule set or type rule.
Other example code includes the following:
.mystyle {color:red}
Such code is referred to as a class rule set or class rule, and this specific class rule set applies a rule that a given object is rendered red. A style in a class rule set may apply to one or more objects, including button objects. An example portion of MXML™ code to produce a button object is as follows:
<mx:Button stylename=“mystyle” background-color=“blue”/>
Assuming that the type rule set above is in the same document as the button, its style rule is applied to the button. However, in order to apply the class rule set to the button, “stylename=mystyle” is included in the MXML™ code that describes the button.
A third way to apply styles through CSS is illustrated by the background color property in the MXML™ code above. The background color rule is referred to as an inline style or inline rule. This particular background color style only applies to this particular button, and is not shared by other buttons. It should be noted that according to the CSS standard, type rules, class rules, and global rules are properly referred to as respective “rule sets,” while inline rules are properly referred to as “inline styles” for convenience. The term “rules” is used herein generically in the context of inline styles class rule sets, type rule sets, and global rule sets. Accordingly, the terms “in line rule,” “class rule,” “type rule,” and “global rule,” are understood to encompass respective styles or rule sets.
The above examples illustrate the different ways that styles may be applied to an object—background color is applied using an inline style, color is applied using a class rule set, and font size is applied using a type rule set. When a user's player, such as client application 105, encounters an event that causes it to have to search for the specific rule that applies a font size to the button above, it must determine which rule sets to look at and in what order to look. Further, the font size could be specified using an inline style, class rule set, and type rule set (although that is not the case in this example), so the client application know which particular style applies.
FIG. 2 illustrates exemplary hierarchy 200 of rules used by the client application 105 (FIG. 1) executing SWF file 103. When searching for the value of a style, client application 105 (FIG. 1) looks at inline rules 201 first. If client application 105 finds the particular style that it is looking for in inline rules 201, it looks no further. Accordingly, inline rules 201 take precedence over other rule sets 202-204 when the same style is defined in multiple places.
If client application 105 does not find the particular style in inline rules 201, it then goes to class rules 202. If client application 105 finds the style in class rules 202, it looks no further and applies the style, but if the particular style is not found in the class rules, it moves on to type rules 203. Accordingly, class rules 202 are below inline rules 201 in hierarchy 200, but are above type rules 203 and global rule set 204. If the particular style is not found in inline rules 201, class rules 202, or type rules 203, client application 105 moves on to global rules 204. Thus, as described above, client application 105 traverses hierarchy 200 until it finds the style that it is looking for.
The searching mechanism described above is implemented in script—in this case, compiled ACTIONSCRIPT™ bytecodes in SWF file 103. SWF file 103 is coded so that whenever the style-finding method is called, bytecodes specify that client application 105 should look at inline rules 201 first, class rules 202 second, type rules 203 third, and global rules 204 last. Accordingly, calling the style-finding method invokes hundreds of lines of bytecodes. Such a large amount of code may result in slow operation when applying styles during runtime, and slow operation may make the application less enjoyable or less appealing to end users.